The Internet Protocol (IP) is the method or protocol by which data is sent from one computer to another on the Internet. Each computer (known as a host) on the Internet has at least one IP address that uniquely distinguishes from all other computers on the Internet. Data is exchanged in the form of packets, with each packet including both the sender's IP address and the receiver's IP address.
As the Internet has grown and evolved, different versions of the IP protocol have been developed to support the changing needs of the Internet. One element of the IP protocol is the mapping of the bits of a packet to different control fields within the packets. For example, version 4 of the IP protocol (IPv4) allocates 32 bits to each of the source and destination IP addresses in the packet. As a result there are 232 available host addresses in an IPv4 network. However, in the face of a huge growth in the Internet, the number of hosts requiring IPv4 addresses may quickly exceed the available IP address supply.
Version 6 of the IP protocol (IPv6) was introduced to overcome some of the limiting elements of IPv4. One improvement of IPv6 protocol is the extension of IP addresses from 32 bits to 128 bits. As a result, the IPv6 addresses are 128 bits in length, resulting in 2128 (which is 3.4×1038) IPv6 addresses.
The large address space of the IPv6 can be made more manageable by the introduction of hierarchies, to reduce the size of routing tables and ease address management issues. There are recommendations within the standards committees that the deployment of IPv6 be done in such a way as to create a route summarization hierarchy. There are two main reasons for this; First, effective hierarchies greatly reduce the route table size to support the network. Second, hierarchies allow for quicker, more effective L3 convergence of major trunks during topology changes as well as allow for more effective summarized route policies.
One IPv6 hierarchy structure is defined in Internet Engineering Task Force (IETF) Request for Comments 3587 (RFC3587). RFC3587 defines a Global Unicast Address Format which includes three fields associated with three different levels in the Global Unicast Address hierarchy: a Public topology field, a Subnet (or Site) topology field and an Interface Identifier field. The Public topology field provides an address space for a collection of providers and exchanges of public Internet transit services. The Site topology field provides a local address space for a specific site or organisation which does not provide public internet transit service to nodes outside of the site. The Interface Identifier field provides addresses of different interfaces on links. Within the address space defined by the Subnet topology field, an organization can decide whether they locally want a flat structure or whether they require further levels in the hierarchy. Thus the hierarchy at the Subnet level is not defined by standards but selected by the organisation in accordance with their needs.
Host devices in an IPv6 network obtain addresses using either a stateful or stateless address auto-configuration mechanism. Stateless auto-configuration requires no manual configuration of hosts; rather the stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an “interface identifier” that uniquely identifies an interface on a subnet. An address is formed by combining the two.
In the stateful autoconfiguration model, hosts obtain interface addresses and/or configuration information and parameters from a server, such as a Dynamic Host Control Protocol (DHCP). DHCP servers maintain a database that keeps track of which addresses have been assigned to which hosts. The stateful auto-configuration protocol allows hosts to obtain addresses, other configuration information or both from a server. Stateless and stateful auto-configuration complement each other. For example, a host can use stateless autoconfiguration to configure its own addresses, but use stateful autoconfiguration to obtain other information. Network security can be enhanced in an IPv6 network through dynamic reconfiguration using the auto-configuration mechanisms described above.
One problem with dynamic reconfiguration and auto-configuration is that, while there are documented procedures for auto-configuration of hosts based on both stateless and stateful methods, these methods assume the presence of an IPv6 router that will either provide the correct IPv6 prefix that the host will use or indicate a managed state addressing environment (DHCPv6) for host use. However, there are no consistent methods for the allocating IPv6 addresses to routing elements. As a result, router IPv6 addresses are typically manually assigned, either by direct Command Line Interface (CLI) configuration or by off-line configuration edits. While manual assignment may be used to manage addresses in small, relatively static networks, it is not a feasible solution for larger more dynamic networks.
The management and allocation of hierarchical addresses to achieve an effectively designed IPv6 network complicates network deployment; In order to leverage the benefits of hierarchical routing, a network designer must figure out the whole addressing hierarchy prior to addressing any of the routing elements in the network topology. This is a computationally simple but repetitive task that is not based in ‘human friendly’ mathematics. Consequently, this approach is not only extremely time consuming, it is also very much prone to human error. In large, mission critical dynamic deployments any such inconsistencies would need to be discovered and resolved in the field. Given that among the many predicted uses for dynamic IPv6 deployments, one of them is the ‘networked battlefield’, such configuration errors could cost lives.
To address these problems, broker systems have been developed that are focused on the setup of IPv6 configured tunnels by standards based methods. The assignment of IPv6 prefix addresses happens as a necessary function in the setup of the IPv6 transition environment. While this approach works, it only works for tunnel brokered deployments and within the address range offered by the brokered system, because the assignment of prefixes is predicated on the presence of a pre-established tunnel. In other words, prefix assignment is an explicit process, and thus this solution has similar drawbacks to other types of manual assignment mechanisms.